       ********    **************************************************
             *    *                                                  *
            *     *                 The independent guide to BITNET  *
           *      *                                                  *
          *       *                                      July, 1988  *
         *        *                                                  *
        *         *                              Volume 3, Number 1  *
       ********   *                                                  *
                  *                                                  *
        ***       *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * * *      *                                                  *
       * **       *                                           ********
                  *                                    ***************
           *      *                               ***************    *
           *      *                         **************           *
       ******     *                     *************                *
           *      *                ************                      *
           *      *            ************                          *
                  *         **********                       *********
       ********   *      *********                     ***************
             *    *    ********                  **************      *
            *     *  *******                *************            *
           *      * ******             ************                  *
            *     ******           ***********                ********
             *    *****        **********               **************
       ********   ****      *********             *************      *
                  ***    ********            ************            *
        ***       **   *******          ***********                  *
       *   *      *  ******         **********                       *
       *   *      * *****       *********                    *********
       *   *      *****      ********                  ************* *
        ***       ****    *******                ************        *
                  ***   ******              ***********              *
       ******     **  *****            **********                    *
           *      *  ****          *********                     *****
           *      * ***        ********                  *************
           *      ****      *******                 ************     *
       ****       ***    ******               ***********            *
                  **   *****             **********                  *
           *      *  ****           *********                   ******
           *      * ***         ********               ***************
       ******     ***       *******            ***********************
           *      **     ******         ******************************
           *      *   *****       ************************************
                  * ****     *****************************************
       ********   ***    *********************************************
           *      **  ************************************************
           *      * **************************************************
           *      ****************************************************
       ****        **************************************************
1


            *     *              *     *                   *
            **    *         *    **   **       *       *   *
            * *   *  ***  *****  * * * *  ***  ****  ***** ****
            *  *  * *   *   *    *  *  * *   * *   *   *   *   *
            *   * * *****   *    *     * *   * *   *   *   *   *
            *    ** *       *    *     * *   * *   *   *   *   *
            *     *  ****   *    *     *  ***  *   *   *   *   *
       *****                                                    ******

       Christopher Condon    Editor                  CONDON @ YALEVM
       Timothy Stephen       Associate Editor       STEPHEN @ RPICICGE
       Craig White           Associate Editor        CWHITE @ UA1VM
       Wendel Bordelon       Contributing Editor    TACVRWB @ TCSVM
       June Genis            Contributing Editor     GA.JRG @ STANFORD
       David Hibler          Contributing Editor   ENGL0333 @ UNLVM
       Henry Mensch          Contributing Editor      HENRY @ MITVMA
       Deba Patnaik          Contributing Editor       DEBA @ UMDC
       Gerry Santoro         Contributing Editor        GMS @ PSUVM
       Marc Shannon          Helpdesk Editor       HELPDESK @ DRYCAS
       Glen Overby           Technical Assistant   NU070156 @ NDSUVM1
       Gary Moss             Pillar of Virtue          MOSS @ YALEVM

       ********************  Contents - Issue 23  ********************


       EDITORIAL PAGE_________________________________________________

       Bitnotes .................................................... 1
       Flames To: .................................................. 7
       Bringing BITNET to the Eastern Bloc ......................... 3

       FEATURES_______________________________________________________

       The NeWS Archive SErver ..................................... 9
       The UTC Name Server ........................................ 10

       DEPARTMENTS____________________________________________________

       Headlines .................................................. 13
       New Mailing Lists .......................................... 12
       Feedback ................................................... 17
       Policies ................................................... 20


       *  For information on  subscribing to  NetMonth,  submitting  *
       *  articles, sending  letters, and  printing this  file, see  *
       *  the "Policies" section on the last pages of this issue.    *

       -----------------------------------------
1

                                                                Page 1


        *********
       *         *  Bitnotes
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  Yale University
       *         *
       *         *  CONDON@YALEVM
        *********


        "Your kindness will never be obliterated by your good looks."


                                   FSFnet
                               12/84 - 08/88


       When  I was  first  learning about  BITNET,   Dave Liscomb  was
       distributing an  announcement of his electronic  magazine,  the
       Fantasy and Science Fiction Network  (FSFnet).   These were the
       days when the network was small (a few hundred nodes) and there
       were no list servers or Relays.  Come to think of it, there was
       no NetMonth, or Bitlist, or BITLIB.   There was only VM/COM,  a
       computer science  interest magazine  distributed by  the people
       who ran  CSNEWS.   If I remember  correctly,  Dave was  a staff
       member of that publication.

       Here was Dave, starting out a magazine of his own.  I found out
       about in  the typical  way that  people found  out about  those
       things in BITNET-1984.    When I was learning  about the CSNEWS
       file server,   I added myself  to the legendary  Bitnauts List.
       Dave sent  out his  announcement to  everybody in  Bitnauts who
       said they had  an interest in Fantasy or  Science Fiction.   It
       seems that I was one of those people.

       About this time, many of you are thinking,  "Big deal.   I have
       not the slightest interest in Science Fiction or Fantasy."  You
       might not realize the important role  that FSFnet has played in
       the development of  the network.   FSFnet was  the first BITNET
       electronic  magazine with  a subject  matter having  absolutely
       NOTHING to do  with computers.   While you may or  may not care
       for the topic, Dave Liscomb showed that the network could be an
       effective form of  communication for people interested  in non-
       computer topics.

       This served as the inspiration  for the early BITNET magazines,
       many  of  which are  still  in  production today.    There  was
       NutWorks (humor), CRTNET (communications), Bitlist...
1

                                                               Page 2


       Bitlist,  the weekly predecessor to NetMonth,  was,  of course,
       based on a computer-related topic.  Early on,  however,  FSFnet
       served as the inspiration for producing an electronic magazine.
       Later,  when Bitlist became NetMonth,   FSFnet was the model of
       consistency and quality I hoped to achieve.

       Dave  is  leading  the  network now,   and  FSFnet  will  cease
       publication.  He has made arrangements for the startup of a new
       magazine to carry on FSFnet projects (see Headlines).  I cannot
       help but  feel,  however,  that  these are,  in  network terms,
       deaths (hence the  eulogy tone of this  editorial).   When Dave
       leaves BITNET that will most likely  be the last contact I have
       with him.     He has  been a  pioneering networker  and a  good
       friend.

       Still, we must not think of this as an end, but as a beginning.
       He is going on to a far better life...  

       The network  will go  on without  Dave Liscomb  and FSFnet,   a
       little less whole because of  their absence,  better because of
       thier presence.

       ***************************************************************

       I have some good news and some bad news.   The good news is the
       staff listing you  see on the second page of  this issue.   The
       people there have generously offered  their time and talents to
       keeping NetMonth going.   I,  of course,  am going to take full
       advantage of them....  er...  this.    In the coming months you
       will see that the various features and news items will be carry
       their bylines.    Their contributions will increase the quality
       and timeliness of the magazine.

       The bad  news is  that there  will be  no NetWeek  this summer.
       There just hasn't  been enough news to justify  sending one out
       every week.  Rather than cancel the whole thing, we will simply
       start it  up again when the  fall semester begins.   Call  it a
       summer vacation.  Since this lack of news happens every summer,
       we will no doubt go on vacation again next year.


                      Virtually,

                              Chris Condon@YALEVM
1

                                                                Page 3



        *********
       *         *  Flames To:
       *         *
       *         *  by Craig White
       *         *
       *         *  University of Alabama
       *         *
       *         *  CWHITE@UA1VM
        *********


       Hello once again,

       I have had a very nice month,   hope you did too.   A couple of
       times during the month, parts of the net that were important to
       me were down for long periods of  time,  but,  overall it was a
       good month  for my  networking activity.    I am  really having
       problems with mail as  there are more lists that I  feel I need
       to read to keep up with the technical aspects of my life.  This
       just means  that my allotted time  for mail is pressed  to it's
       limit.   Unfortunately,  I've had to unsubscribe to some of the
       more esoteric digests that often make my day a little brighter.
       It seems I am becoming a  solely technical person.   Maybe I'll
       just resubscribe and  allot a little bit more time  for mail so
       that  I can  have time  to  relax with  some non-computer  type
       mailing lists.

       I've been meaning to address this for  some time now but I just
       keep forgetting to put it in the article:  I appreciate all the
       mail I get from people who read  the column and I do read every
       one.   Normally, I do not respond to those of you who write but
       this by no means indicates that  I'm not interested in what you
       think.   I think many people have noticed that I've used gripes
       of theirs  in my columns and  when I feel that  it's absolutely
       necessary that you get a response I do send one off.  I'm sorry
       that I'm  not able  to answer  every letter  that I  get but  I
       promise I  take what you  say seriously and  I do read  and use
       ideas that are sent to me.

       This months  flame is  about the flood  of mailings  that often
       occur following a  large posting,  a multiple  list posting and
       often flames.    What I'm talking  about is the  many follow-up
       posting to the effect of;  "I had  to discard that note from XX
       number of lists that  I'm on and I'm sick of  seeing that piece
       of mail";   Or,  "I wish so and  so would take their gripes off
       the  list  and discuss  them  privately."   I hate  to  discard
       multiple posting  and I also  get tired of  discarding personal
       flames.
1

                                                                Page 4


       This particular topic is a very hard one for me because, on the
       one hand I think that the way  changes in net behavior occur is
       for fellow networkers  to write and gently  chastise each other
       for behaviors that they think are inappropriate or that violate
       the official  rules of conduct.    On the other  hand,  sending

       these to the list costs a  lot in terms of traffic,  especially
       when it is made public via a list.  It seems that somehow these
       proddings need to be private.   Unfortunately, by doing this we
       are not allowing  newcomers to the net world  an opportunity to
       find out  what the  unspoken rules  of the  game are.    At the
       moment with  our current network  saturation level,   we cannot
       afford  to allow  a  few to  learn at  the  expense of  others.
       Therefore,   I  am  recommending  that if  a  person  makes  an
       inappropriate  posting and  you feel  the need  to flame  them,
       please make it private.  If 10 people feel the need to make the
       same flame then fine.   If it's  private,  there are a lot less
       copies of that flame moving around.    This could really add up
       on some of the more popular lists.

       Finishing up, I think that when someone posts something that is
       inappropriate we  should GENTLY  (that means  without insulting
       someone's intelligence,  family,  family  to be)  chastise that
       person PRIVATELY  about their behavior.    You will want  to be
       sure  to include  logical  arguments  and possible  alternative
       actions rather than blast them for their error.

       It was brought to my attention  this month that LDBASE COM (the
       LDBASE program for  the VAX)  is not yet available.    I do not
       know the current status of this project but maybe there will be
       more  news  about  this  next  month.    As  always  questions,
       comments, and Flames should be sent to CWHITE@UA1VM.
1

                                                                Page 5


        *********
       *         *  Bringing BITNET to the Eastern Bloc
       *         *
       *         *  by David J. Hibler
       *         *
       *         *  University of Nebraska-Lincoln
       *         *
       *         *  ENGL0333@UNLVM
        *********


       Jason Ohler's provocative  article ("Let's Bring BITNET  to the
       Soviet  Union")   in the  May  issue  of NETMONTH  has  already
       elicited  comment,   but much  more  still  needs to  be  said.
       Personally, I think the proposal is a very sound one, and I had
       toyed with suggesting the same a  few months back but never got
       around to writing  up the ideas.   I'd like to  thank Ohler for
       bringing the issue into public view so it can be discussed more
       widely.

       The  fundamental   assumptions  behind  Ohler's   proposal  are
       certainly quite valid.  It is in the best interests of everyone
       if we can  find ways for direct and  peaceful interchanges with
       the Soviets rather than military ones.  And he is quite correct
       in asserting  that advances in  modern technology  have bridged
       previously insurmountable barriers of  physical distance.   Yet
       let us not be naive about what  may be one of the most profound
       obstacles  to  be  overcome before  such  an  exchange  becomes
       possible:  the  seemingly insurmountable barriers  of political
       paranoia,  hostility  and intransigence  on BOTH  sides of  the
       ocean.

       Ohler asserts that "to allow BITNET  to become the same kind of
       force that  it has become  in the west is  asking a lot  from a
       government  that has  presided  over an information constrained
       culture  for half  a century,"  thus implying  that the  Soviet
       government would be  the one which felt most  threatened by any
       such exchange.   In  his June commentary on  the article,  Dave
       Phillips picks  up this theme and  develops it even  further by
       asserting, "this would be a great idea if and only if access to
       the links  at the Soviet side  were not rigidly  controlled and
       rationed to 'reliable'  people." Both are generally  correct in
       acknowledging the existence  of previous  Soviet  restraints on
       the flow  of information,  though there  is certainly no better
       time than the present  to test  whether  or  not  glasnost  and
       perestroika have truly altered the Soviet landscape.   But both
       are incorrect if they mean to  imply that the Soviet government
       is the  only government which  might have reservations  about a
       computerized linking of our cultures.
1

                                                                Page 6


       For just as crucial as the question of Soviet resistance is the
       question of U.S.   roadblocks to such a venture.   Recent years
       have seen direct Presidential interdictions  on the exchange of
       high-tech  with the  Soviets.    Our  government seems  acutely
       sensitive to the transfer  of computer-based technologies,  for
       it is particularly in this area that we enjoy a commanding lead
       on the Soviets.  Put in simple terms, it is quite possible that
       some people in our government might  see a BITNET link with the
       Soviets more  as a threat  to our  national security than  as a
       means   of  advancing   intercultural   dialogue  between   our
       respective peoples.

       And  if we  are to  be perfectly  honest,  such  fears are  not
       entirely groundless.    As we  all are  quite aware,   even the
       people who invent  systems do not always know how  they will be
       applied or what capabilities they might eventually assume.  For
       proof,  simply  look at the  way in  which BITNET or  e-mail in
       general have evolved in only a  few short years.   And once the
       technology is in place,  who is really in a position to control
       what is sent out over it? Such an information transfer would no
       doubt be  a two-way street.    Just as the  Russian bureaucracy
       might tremble  at the  implications of  its citizens  in direct
       link with the West because of  the social implications,  so the
       American bureaucracy  will no  doubt tremble  at the  ease with
       which sensitive databases might end up in Soviet hands.

       In my mind,   the opportunities are well worth  the risks,  for
       personally  I feel  we will  be in  a much  better position  to
       impress their citizens with our friendliness, our openness, our
       excitement,  and  our eagerness to  learn--and to  be similarly
       impressed in turn by their  own citizens--than the Soviets will
       be  to steal  secrets which  they'd  otherwise probably  pilfer
       eventually anyway.

       But more is needed now than  merely raising the idea.   Someone
       must take  up the standard and  advance the issue,   keeping in
       mind  that  there  will undoubtedly  be  resistance  from  both
       governments.    As the  issue  is advanced,   there  must be  a
       comprehensive strategy which  will allow both sides  to explore
       the implications of such an exchange without suffering any loss
       of face.   Such a strategy might contain at least some elements
       of the following proposal.

       First,   General  Secretary  Gorbachev  should  be  approached,
       probably through  the cultural liaison  at the  Soviet Embassy,
       and asked  directly whether or not  his view of  glasnost would
       permit communication via computer by students and professors at
       Soviet  universities   with  their  counterparts   at  American
       universities.    If he  responds negatively,   there is  really
1

                                                                Page 6


       little point in  pursuing the matter any further  at this time.
       For if the  principal architect of perestroika is  not in favor
       of the idea,  don't expect any  of his subordinates to advocate
       it.   But  if he responds positively  and indicates at  least a
       willingness to discuss the matter further, then the monkey will
       be on our back and we will need to confront those who are about
       to be in power as to their intentions in this regard.

       Notice the careful phrasing of that last sentence, for there is
       little  point  in  initiating   discussions  with  an  American
       administration which has less than a half-year left.  But there
       might be  much point  in presenting  such an  issue to  the two
       Presidential contenders  and seeing if  substantive differences
       in this regard exist between the major parties.   Indeed,  such
       an  inquiry  might  even  make an  interesting  addition  to  a
       Presidential  debate--for  we've  listened  to  the  candidates
       belabor  the other  issues  for months  now,   but we've  heard
       precious little about how either party might go about improving
       the  cultural and  educational climate  between our  respective
       peoples.

       Some closing notes.   Ohler cites an American professor who has
       managed to establish e-mail links with his Soviet counterparts,
       but does anyone  know of any other  instances?   In particular,
       does USENET have any such links?  Finally,  why should we limit
       ourselves only to  Soviet links as Ohler suggests  or to Polish
       links as Phillips counterproposes?   Why not simply advance the
       concept of  opening the entire  Eastern bloc to  BITNET access?
       And why stop there? How about the mainland Chinese? Are they to
       be ignored?  We fashion ourselves  a "world-wide" network,  but
       isn't it time we took steps to live up to that billing?
1

                                                                Page 7


        *********
       *         *  The NeWS Archive Server
       *         *
       *         *  by the NeWS Archive Manager
       *         *
       *         *  Sun Microsystems
       *         *
       *         *  MANAGER-NEWS-ARCHIVE@SUN.COM
        *********


       The NeWS   Archive   Server   at    Sun   Microsystems   (NEWS-
       ARCHIVE@SUN.COM)  is a mail-response program.   That means that
       when you  mail a request  to the server,   it will mail  back a
       response.

       The file server does not perform extensive error checking.   If
       you do not  send the server commands that  it understands,  the
       response will be:  "I don't understand you."

       The file server has several commands. Each command  must be the
       first  word on  a line.    The  file server  reads your  entire
       message  before it  does  anything,  so  you  can have  several
       different commands in a single message.  The file server treats
       the "Subject:"  header line  just like  any other  line of  the
       message.   You can use any combination  of upper and lower case
       letters in the commands.

       The archives  are organized  into a  series of  directories and
       subdirectories.   Each  directory has an  index,  as  does each
       subdirectory.   The  top-level index gives  you an  overview of
       what is in each of the  subdirectories,  and the index for each
       subdirectory tells you what it contains.

       If you  are bored  with reading documentation  and want  to try
       something, send the server a message containing the line:

           SEND INDEX APPLICATIONS

       When you get the index back,  it will give you the names of all
       of the application program files  in the archive.   Next,  send
       the server another message asking it to send you the files that
       you want:

           SEND APPLICATIONS SUNCLOCK

       You should send the commands to NEWS-ARCHIVE@SUN.COM.

1

                                                                Page 8


       Commands:

       The four server commands:

       HELP command:    The command  HELP (or  SEND HELP)   causes the
       server  to send  you the  help  file.   No  other commands  are
       honored in  a message  that asks for  help (the  server figures
       that  you  had better  read  the  help  message before  you  do
       anything else).

       INDEX command:  If your message contains a line where the first
       word is INDEX,  the server will send you the top-level index of
       the archive contents.     If there are other words  on the line
       beginning with  INDEX that  match the  name of  subdirectories,
       then the indices  for those subdirectories are  sent instead of
       the top-level index.  For example, you can say:

               INDEX
           or
               INDEX APPLICATIONS
           or
               INDEX DEMOS

       You can then send another message  to the file server,  using a
       SEND  command (see  below)  to  request the  file(s)  that  you
       learned  from  the  response  to  the  INDEX  command.    INDEX
       APPLICATIONS and SEND  INDEX APPLICSTIONS mean the  same thing.
       That is,   you can use  the SEND  command instead of  the INDEX
       command, if you want, for getting an index.

       If your message has an INDEX or a SEND INDEX command,  then all
       other  SEND commands  will be  ignored.   This  means that  you
       cannot get an index and files in the same request.  (This is so
       index requests can be given high priority.)

       SEND command:   If your message contains a line where the first
       word is SEND, the server will send you the item(s) named on the
       rest of  the line.    To name  an item,   you must  specify its
       directory (category) and its name. For example:

               SEND DEMOS COLORTABLE
           or
               SEND APPLICATIONS SUNCLOCK

       Once  you have  named a  subdirectory (or  category),  you  can
       specify more than one item on the rest of the line.   They will
       all be retrieved from that category.  For example:

               SEND DEMOS COLORTABLE SLIDER CLIENT
1

                                                                Page 9


       Each SEND  command can reference  only one  subdirectory.   For
       example,   if you  would  like  to be  sent  one  demo and  one
       application, you must use two SEND commands: one beginning SEND
       DEMO and the other beginning SEND APPLICATION.

       You  may put  multiple  SEND commands  in  one  message to  the
       server, but the more items you request, the longer it will take
       to receive.   (See "FAIRNESS" below, for an explanation.)   The
       number of  send commands is limited.    If the server  must use
       uucp mail  to send your files,   then it cannot send  more than
       100K bytes in  one message.   If you  ask for more than  it can
       send,  the server  will send as much  as it can and  ignore the
       rest.


       Notes:

       Don't send mail  with long lines.   If  you want to ask  for 20
       files in one request,  you don't need  to put all 20 of them in
       one "send" command.    The file server is quite  able to handle
       long lines,   but before your mail  message is received  by the
       file server  it might  pass through  relay computers  that will
       choke on long lines.


       Fairness:

       The file server  contains many safeguards to ensure  that it is
       not monopolized  by people  asking for  large amounts  of data.
       The mailer is set up so that it  will send no more than a fixed
       amount of  data each  day.   If  the work  queue contains  more
       requests than the day's quota,  then  the unsent files will not
       be processed until the next day.  Whenever the mailer is run to
       send its day's quota, it sends the shortest requests first.

       If you have a request waiting in the work queue and you send in
       another  request,  the  new request  is  added to  the old  one
       (thereby increasing  its size)  rather  than being  filed anew.
       This prevents you from being able to  send in a large number of
       small requests as a way of beating the system.

       The reason for all of these  quotas and limitations is that the
       delivery resources are  finite,  and there are  many people who
       may like to make use of the archive.

1


                                                               Page 10


        *********
       *         *  The UTC Name Server
       *         *
       *         *  by the UTC Name Server Manager
       *         *
       *         *  University of Tennessee
       *         *
       *         *  UTSERVER@UTKVM1
        *********


       UTSERVER@UTKVM1 is a service machine  written by the University
       of  Tennessee  Computing  Center to  provide  additional  PROFS
       services.  The main  function of UTSERVER  is to update  an on-
       line electronic mail directory, and to perform housekeeping and
       cleanup  functions   associated  with   this  electronic   mail
       directory.

       The University  of Tennessee  Computing Center  electronic mail
       directory  contains  user  name,    userid,   and  BITNET  node
       information for non-student UTCC timesharing accounts.   It may
       contain additional information, including the user's department
       abbreviation and office telephone number.

       Users on  one of the  University of Tennessee  Computing Center
       BITNET nodes can  issue commands (via BITNET)   to delete their
       entry from the electronic mail directory.  All BITNET users can
       issue commands  to search  for entries  in the  electronic mail
       directory.

       All BITNET users can search  the directory for string arguments
       by issuing one of the following commands.   From a VM/CMS host,
       the command is:

            TELL UTSERVER AT UTKVM1 FIND string

       From a VMS host, the command is:

            SEND UTSERVER@UTKVM1 FIND string

       In both of these examples, "string" is the search argument.  It
       may  contain an  asterisk as  a  "wildcard",  and  is not  case
       sensitive.   The  result from the search  will be a  file which
       contains all entries in the  directory which contain the search
       string.   A message which tells  the number of matching entries
       will be sent to your  timesharing userid.   If matching entries
       are found,   the file containing  the matching entries  will be
       returned to your CMS reader or to your JNET receive area.
1

                                                               Page 11


       If  an initial  search of  the  directory does  not return  the
       information you are searching for,   enlarging the scope of the
       search or changing  the search arguments sometimes  will return
       the results you are searching for.   For example, if you search
       for "Smith,  John",  and cannot  find John Smith's entry,  then
       performing two searches, one for "Smith" and one for "John" may
       provide the results you are searching for.


        *********
       *         *  Headlines
       *         *
       *         *  Smaller bytes of news, but not unimportant...
       *         *
       *         *  by Christopher Condon
       *         *
       *         *  send them to BITLIB@YALEVM
        *********


       * PolymerP FILELIST:   The  PolymerP filelist on LISTSERV@HEARN
       and LISTSERV@RUTVM1 stores a new Polymer Physics Database.  The
       Database is intended  for information which is  of interest for
       the  polymer  physics  community,   such  as  email  addresses,
       projects, software, physical data, meetings, vacancies, etc.

       The database is related to the Polymer Physics Discussion list,
       an open  discussion group dealing  with all relevant  topics in
       polymer physics.    You can  receive the  PolymerP filelist  by
       sending   the   following   command    to   LISTSERV@HEARN   or
       LISTSERV@RUTVM1 via mail or message: INDEX POLYMERP.

       * FSFnet:   With the distribution  of issue 11-3 in mid-August,
       the FSFnet electronic fantasy and science fiction magazine will
       cease publication due to the graduation of its editor, David A.
       Liscomb (CSDAVE@MAINE).   FSFnet began  publication in December
       of  1984 and  has  produced nearly  50  issues.   The  magazine
       initiated  a  shared-world  writing group  called  'the  Dargon
       Project',   and this  group  will  continue to  produce  Dargon
       stories.   These  stories will  be printed  in a  new magazine,
       edited by John White (WHITE@DUVM),   which will replace FSFnet.
       All readers who are subscribed to  FSFnet at the time of 11-3's
       distribution  will  automatically  be  subscribed  to  the  new
       magazine,  or subscriptions  may be obtained from  Mr.   White.
       Back   issues   of   FSFnet  are   currently   available   from
       LISTSERV@TCSVM.
1

                                                               Page 12

        *********
       *         *  New Mailing Lists
       *         *
       *         *  by Rich Zellich
       *         *
       *         *  from List-of-Lists
       *         *
       *         *  ZELLICH@SRI-NIC.ARPA
        *********


       DISARM-L

       DISARM-L provides off-line and on-line discussion (with monthly
       logs)   on  ways  to  accelerate  disarmament.    Topics  cover
       political, peace movement strategy,  and military strategy (for
       technological  discussions   try  ARMS-D@XX.LCS.MIT.EDU)    for
       reducing  nuclear,   conventional,  chemical,   and  biological
       weapons and forces.   Also  reducing destabilizing intervention
       in  the Third  World  by the  Superpowers.    We  want a  broad
       membership (especially Europeans, Asians, Latin Americans)  and
       lively debate; non expert grass-roots opinions are welcomed.

       To subscribe,  send the  following command to LISTSERV@ALBNYVM1
       via mail or message:  SUB DISARM-L your_full_name.

       Coordinator: Donald Parsons
                    DFP10@ALBNYVM1


       EPID-L

       Mailing  list   for  the  discussion   of  current   topics  in
       Epidemiology and Biostatistics.

       To subscribe, send the following command to LISTSERV@AQUCDN via
       mail or message:  SUB EPID-L your_full_name.

       Coordinator: Robert C. James
                    JAMESRC@QUCDN


       FWAKE-L

       A forum  for a broad  discussion about James  Joyce's FINNEGANS
       WAKE.   The James  Joyce Institute of Ireland's  Finnegans Wake
       Study  Group has  been doing  their best  to get  the jokes  in
       Finnegans Wake  for the  past decade or  so.   The  Study Group
       thinks it is time for such groups to pool their findings.
1

                                                               Page 13


       There are plans  to start a second associated  service to share
       page-by-page,  line-by-line notes to the text of FINNEGANS WAKE
       in  a  fixed  format  analogous  to  that  of  Roland  McHugh's
       ANNOTATIONS.   The Coordinator  is working on a  program to vet
       the mail from such a service.

       All requests to  be added to or deleted from  the mailing list,
       or  to  have   files  distributed,   should  be   sent  to  the
       Coordinator.

       Coordinator: Michael O'Kelly
                    MOKELLY@IRLEARN


       HOMEBREW

       The Homebrew  Mailing List is  primarily for the  discussion of
       the making and tasting of beer, ale, and mead.  Related issues,
       such as  breweries,  books,  judging,  commercial  beers,  beer
       festivals, etc,  are also discussed.   Wine-making talk is also
       welcome, but non-homeade-wine talk is not.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,   should  be   sent  to  HOMEBREW-
       REQUEST%HPFCMR@HPLABS.HP.COM.

       Coordinator: Rob Gardner
                    RDG%HPFCMR@HPLABS.HP.COM


       INFO-CAMAC

       Topics  relevant  to  any Computer  Automated  Measurement  And
       Control (CAMAC) hardware or software issue are appropriate.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,   should be  sent  to  INFO-CAMAC-
       REQUEST@KL.SRI.COM.

       Coordinator: Richard Steinberger
                    STEINBERGER@KL.SRI.COM


       INFO-PDP11

       INFO-PDP11 is an unmoderated mailing list for discussion of any
       and   all   issues   relating  to   Digital's   PDP-11   series
       minicomputers and their operating systems.
1

                                                               Page 14


       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,    etc.,    should  be   sent   to   INFO-
       PDP11-REQUEST@SEI.CMU.EDU.

       Coordinator: Pat Barron
                    PDB@SEI.CMU.EDU


       iPSC

       Mailing  list to  allow  iPSC/1 and  iPSC/2  users and  systems
       administrators  from  different  installations  to  communicate
       easily and directly.

       Local aliases  for this mailing list  are to be handled  by the
       local systems  administrators,  since  most sites  already have
       local user mailing lists.   What is desired to accomplish is to
       link  all these  iPSC user  lists together.    The first  thing
       needed  is  an  administrator  list  and  the  user  list  will
       hopefully follow.   If you are a system administrator for Intel
       Hypercube(s)  you are invited to send the following information
       to IPSCLIST@TCGOULD.TN.CORNELL.EDU:

          - systems, iPSC/1's or iPSC/2's
          - administrator's e-mail address OR alias
          - institution
          - user alias list
          - suggestions, opinions, ideas....

       PLEASE! Systems Administrators Only.

       Coordinator: Dave Fielding
                    FIELDING@TCGOULD.TN.CORNELL.EDU


       MVSTCPIP

       A mailing list for discussion of MVS TCP/IP implementations.

       To subscribe,  send the following command to LISTSERV@USCVM via
       mail or message:  SUB MVSTCPIP your_full_name.

       Coordinator: Deba Patnaik
                    DEBA@UMDC


       NEWSB-L

       This  list is  a  forum for  discussion  of  issues related  to
       college  News  Bureaus.    Expected  topics  include:    common
1

                                                               Page 15


       controversial   campus   issues,   press   releases,    general
       information exchange,  and building a network of contacts among
       staff in this field.

       To subscribe, send the following command to LISTSERV@BUACCA via
       mail or message:  SUB NEWSB-L your_full_name.

       Coordinator: Kim Billings
                    K_BILLINGS@UNHH


       OZONE

       This  list is  run by  a group  of researchers  of the  Italian
       National Council (C.N.R.),  working at the CNUCE Institute,  to
       awaken  sensitivity   of  people  working  in   the  scientific
       institutions  about  the  extremely   serious  problem  of  the
       pollution in the world.   We believe the hole in the ozone, the
       "hot-house effect",  acid rains,  and toxic waste are disasters
       provoked by man  by using Nature as  a "never-ending" resource.
       Everybody can  verify other effects  of the pollution,   in the
       cities,  in the seas,  in the rivers,  etc.   We think that the
       scientific community  must create an  opinion movement  able to
       force some decisions at political level.

       To subscribe,  send the  following command to LISTSERV@ICNUCEVM
       via mail or message:  SUB OZONE your_full_name.

       Coordinator: Erina Ferro
                    ERINA@ICNUCEVM


       PCSUPT-L

       A users' group for  the discussion of issues  that address end-
       user  support for  IBM PC's  and  similar microcomputers.    By
       providing a central forum for  users worldwide,  the group will
       foster the timely  communication of solutions to  problems with
       hardware, operating systems, and applications.  The group is to
       include technical  support professionals as  well as  those who
       find  themselves   in  the   role  of   ad  hoc   "PC  expert".
       Participants in the  group will determine what  specific issues
       are discussed.

       To subscribe, send the following command to LISTSERV@YALEVM via
       mail or message:  SUB PCSUPT-L your_full_name.

       Coordinator: Bob Boyd
                    RWBOYD@YALEVM
1

                                                               Page 16


       PSTAT-L

       A forum for  the exchange of information about  the P-STAT data
       management and statistics package;  code, macros, applications,
       user news, user group reports etc.

       All requests to  be added to or deleted from  the mailing list,
       or  to  have   files  distributed,   should  be   sent  to  the
       Coordinator.

       Coordinator: Peter Flynn
                    CBTS8001%IRUCCVAX


       SIMULATOR-USERS
       SIMULATOR-BUGS

       Mailing  list to  allow users  of  the Rochester  Connectionist
       Simulator to talk to one another.

       Please send BUG REPORTS to SIMULATOR-BUGS@CS.ROCHESTER.EDU.  We
       are interested  in fixing bugs,   but can't make  any promises!
       Please make your bug reports as specific as possible.

       All  requests  to  be  added to  or  deleted  from  this  list,
       problems, questions,   etc.,   should  be  sent  to  SIMULATOR-
       REQUEST@CS.ROCHESTER.EDU.

       Coordinator: Liudvikas Bukys
                    BUKYS@CS.ROCHESTER.EDU
1

                                                               Page 17


        *********
       *         *  Feedback
       *         *
       *         *  a letters column
       *         *
       *         *  "You PRO, we PRO, we don't go for REPRO!"
       *         *
       *         *  send your letters to BITLIB@YALEVM
        *********


       From:     Jim Cerny 
       Subject:  David Benson's comment in "Feedback"

       I just  finished reading  the June issue  of NETMONTH  and,  as
       usual, found a number of interesting tips and items.

       This is  a further thought/comment  on David Benson's  wish (in
       the June "Feedback" section) for institution names.

       Early-on in our use of BITNET (way back, about a year ago!), we
       realized that  many node addresses  are pretty cryptic.    As a
       very simple,  but very useful,  tool  for my own use as Inforep
       and for our users, we created a VAX/VMS command ("symbol") that
       uses the  VMS SEARCH  utility to  find matches  to a  specified
       string in  one of the files  that lists BITNET nodes.    We use
       BITNET.LINKS.   This saves us having  to tell people that there
       even *is*  a VMS  SEARCH facility,  since  the average  user is
       probably unaware of it.   When they give our local command that
       enables  BITNET  use,   it  automatically  defines  the  symbol
       BITSITES for them as

           $ BITSITES == "SEARCH our_library:BITNET.LINKS"

       So, to follow Benson's example, they could just say

           $ BITSITES UA1VM

       to see where it is.   Or,  what we find is more common,  people
       want to know if a given school has a BITNET node,  so then they
       might say

           $ BITSITES EMORY

       to check out Emory University.

       A final  way that  it is useful  is in  the process  of reading
       mail.   Suppose you read a message  and want to reply,  but for
       some reason it  is not clear from the message,   where the site
1

                                                               Page 18


       is.  Without leaving VMS mail, they can give the command

           Mail> SPAWN BITSITES EMORY

       How straightforward it is to find direct equivalents to this on
       various IBM and other operating systems, I have no idea, but as
       I say, on a VAX/VMS system it is both simple and very useful.

       * Editors  note:   Some IBM  nodes have  an EXEC known  as NODE
       which  will  list  information such  as an  institution's name,
       inforep, computer type, and so on.  We distribute this with the
       BITLIB help system.

                                                                                      c
       From:     Eric Thomas 
       Subject:  REPRO feature

       1.  I am not at all sure  that the majority of users agree with
       Tony d'Angelo.   I personally find it  a bit irritating  to get
       interrupted by new mail which is in  fact a copy of what I just
       sent.  I know what I have said, and just have to discard it and
       get back to what I was doing.  Most people seem to be satisfied
       with the present setup.

       2.   You  DO  get  an acknowledgement  that  your  mailing  was
       successfully  processed,  unless  you turn  the  option off  of
       course. After 2-3 postings, users come to rely on the fact that
       LISTSERV  works and  that,  when  it  says your  mail has  been
       distributed, it has indeed been.

       3.  Sending you back a copy increases network load,  especially
       for "digest" type lists.


       From:     Rodney Elin 
       Subject:  REPRO feature

       This is in response to the  letter published in Netmonth Volume
       2 Number 12, by Tony D'Angelo.  In his letter, he discusses the
       LISTSERV REPRODUCE option,  which is a flag allowing the sender
       of a message to a list to receive a copy of his/her submission.

       Currently,  the overwhelming majority of lists on LISTSERV have
       the REPRO option set to "NO",   so that the originator does not
       receive a copy of the message from the LISTSERV.  Mr.  D'Angelo
       calls for  all lists  and for future  revisions of  LISTSERV to
       have the  default REPRO option be  "YES",  so that  each sender
       would receive a copy of  his/her posting unless each individual
       changed the option,  for each list to which he is subscribed.
1

                                                               Page 19


       I am  opposed to his suggestion,    and would like to  voice my
       support of the "status quo".   Mr.  D'Angelo gives two explicit
       reasons for receiving a copy of  his postings,  the first being
       simply "just  to see how it  looks...Ã•to seeÃ¥ if there  are any
       gross  errors in  the  message." This  is  unnecessary,   as  a
       writer, using ANY medium and not just electronic mail,   should
       thoroughly proofread all  that he writes before he  sends it to
       be read,  published,  or critiqued.  Mr.  D'Angelo is proposing
       that, with the use of the REPRO=YES option,  a writer proof his
       material AFTER it  is published,  which is unheard  of from any
       writer's point of view.  As for seeing how something looks,  as
       long as the LOG option is in  effect,  which is the default for
       almost all mailers,  a copy of each  mail file sent is saved on
       the sender's disk,   and immediately,   without waiting for the
       LISTSERV,  can  the sender  see how his  mail looks  (though he
       should know this before it is sent.)

       Mr. D'Angelo also states that the REPRO=YES option is needed to
       find  out "if  and when  Ã•the postingÃ¥  got distributed."  This
       is  also  not  necessary,  as  LISTSERV  additionally  supports
       several levels of acknowledgement for  each user and each list,
       including   no   acknowledgement    (SET      NOACK),
       acknowledgement   by  interactive   messages  (SET   
       MSGACK),  and mail acknowledgement  (SET  ACK),  from
       each  peer  of  a  particular  list.   Using  message  or  mail
       acknowledgment is preferable to a copy of the posting, as it is
       a  small,   concise  message,   with  statistics involving  the
       distribution  volume  and time.    Message  acknowledgement  is
       faster than a copy,  and tells the sender exactly when (and if)
       a posting was re-distributed to all subscribers of a list.

       What Mr.   D'Angelo fails  to mention  is the  impact a  global
       default of  REPRO=YES would have  on network load.   During the
       summer months, the network is relatively fast, due to the fewer
       number of  users.  But beginning  in September,  more  and more
       people will use  BITNET,   meaning a heavier  and heavier load,
       especially on major links.   The fewer  files and mail that are
       sent through the  network,   the less load that will  be on the
       network, and the faster other information can be sent.

       In  his  letter,   Mr.    D'Angelo   explains  exactly  how  an
       individual, for whatever reason,   can set his individual entry
       in a list to REPRO=YES when the default is NO.   This is one of
       the main  reasons for  keeping things the  way they  are.   The
       default for all lists SHOULD be NO, in the interests of keeping
       down network  load,   but  anyone can change  this for  his own
       entry just as simply as he subscribed to the list.

       * Editors  note:   Enough  said on  this subject.    I probably
       should have  made similar comments  when I printed  the letter,
1

                                                               Page 20


       but hindsight is 20/20, no?  Also, many of you will be happy to
       see  that I  have  given  in and  will  now  print the  network
       addresses of people who send letters to Feedback.


        *********
       *         *  NetMonth Policies
       *         *
       *         *  Everything you ever wanted to know...
       *         *
       *         *  ...but were afraid to ask.
       *         *
       *         *  BITLIB@YALEVM
        *********


       NetMonth is a  network service publication distributed free  of
       charge to  students  and  professionals  in  Bitnet  and  other
       networks. This magazine and its companion file, BITNET SERVERS,
       are the  work  of the  Bitnet Services Library (BSL) staff  and
       contributors from around the network.

       BITNET SERVERS is BITNETs list of servers and services.  If you
       know of servers not listed in BITNET SERVERS, or if some listed
       are no longer available, please contact the NetMonth Editor.

       * Subscribing to NetMonth and BITNET SERVERS:

       Send  the  following  command  to  LISTSERV@MARIST  by  mail or
       messgage:

            SUBSCRIBE NETMONTH Your_full_name

       Internet users may use this method, but must  address  the mail
       to LISTSERV%MARIST.BITNET

       * Back issues:

       BITNET users  may get NetMonth back issues from the file server
       NICSERVE@BITNIC.

       A subscriber  can delete  him/herself from  the mailing list by
       sending LISTSERV@MARIST the UNSUBSCRIBE NETMONTH command.

       * Letters to the Editor:  If  you  have  questions  or comments
       about BITNET or  NetMonth that you would like  to  see  printed
       here, mail  your letter  to BITLIB@YALEVM.  Make  sure that you
       specify in the "Subject:"  header or  somewhere  in  the letter
       that it is for the NetMonth letters column.
1

                                                               Page 21


       * Article Submissions:  The  only  requirements  for   NetMonth
       articles and columns are that they be informative, interesting,
       and concern some BITNET-related topic.  Send your articles  and
       to BITLIB@YALEVM.

       * Printing this file:  VM  users can print  this file  by using
       the "( CC" option of  the PRINT command.   VAX/VMS users should
       RECEIVE NetMonth  with a  format of  FORTRAN.  This  will allow
       page-breaks to be accepted by your printer.


            _
           __-
          __---    The
         __-----   Bitnet
        __-------  Services
       ___________ Library                       "Because We're Here."

       ***************************************************************
